All Categories :
Servers
Chapter 4
The People Skills to Make it Work
CONTENTS
Here, you turn to the skill sets that you and your Intranet team
will need. Most of these skills are directly related to Web matters-server
administration, CGI script programming, and the like-but others
are routine, computer system administration skills. As your Intranet
develops into a mission-critical system for your organization,
both sets of skills become crucial.
Part II, "Getting Set Up on the Server," gives you a
good deal of information on Web server setup, but you'll eventually
want to consult a more detailed reference. One such book is Web
Site Construction Kit for Windows NT by Christopher Brown
and me (ISBN 1-57521-047-9), published by Sams.net.
Obviously, the very first set of people skills you need are those
encompassing basic Web server setup and administration. This set
of skills is also probably the single most important one to the
success of your Intranet. I'm referring to the areas of content
design, document conversion, security control, and even CGI programming.
Your Webmaster
Your choice of a model for the administration of your Intranet
(see the discussion of these models in Chapter 2,
"Planning an Intranet") has important corollary choices,
most importantly with respect to your need for a Webmaster.
The Webmaster is the person with overall responsibility for setting
up and maintaining your Web server(s). If you choose the centralized
or mixed model, your Webmaster is the most critical part of your
Web. Although many organizations add Webserver administration
to the responsibilities of existing staff, a growing number of
companies are creating dedicated positions. In fact, Webmastering
skills are in high demand, with salaries to match. A recent survey
of Webmasters in Fortune 500 companies by Web Week magazine
showed a full two-thirds of corporate Webmasters earning more
than $45,000, and nearly 40 percent with salaries over $65,000,
reflecting the value companies place on their skills.
However you assign responsibilities in this area, it's vital that
you recognize the value of your Webmaster(s) and ensure he has
the skills he needs. This might seem to contradict earlier statements
about the relative ease of basic Web server setup and the simplicity
of HTML. In fact, although it's true you can set up a simple Web
server on a PC using point-and-click methods and have it running
in a few minutes, setup and administration of a major Web server,
with fill-in forms, CGI scripts, Java applets, appropriate security,
and all the other extras you and your customers will want added
is considerably more involved and requires additional skills.
Just as you shouldn't skimp on the hardware to run your Web server,
don't expect to save money in the long run by throwing an inexperienced
staffer into the job of setting up and running a major Web server.
Because your Webmaster is such a vital cog in your Intranet, we'll
devote a good deal of attention to the skills he or she needs.
If you're unsure where to look for your Webmaster, experienced
system administrators make good choices for Webmasters because
they already have many of the needed skills. You might have potential
Webmasters in your MIS department. There are few experienced system
administrators who don't already have these skills and knowledge,
even if they've never set up a Web server-an increasingly rare
situation, with the rapid growth of the Web. It can't be overemphasized
that many of the most useful and important details of Web server
setup are less than obvious to people who are used to installing
software by double-clicking a:\setup
in Microsoft Windows Explorer (or File Manager). Proper system
administration of a network is part science and part art. The
accumulated experience and intuition of a good system administrator
can keep your Web server in top shape, tuning the performance
of the server and ensuring the system is available "24-7."
If your Intranet becomes mission critical, you'll want a seasoned
Webmaster running it.
Look at some of the most critical skills your Webmaster will need.
I'm assuming here that your Web server will be running Windows
NT (and perhaps BackOffice), of course.
Web Server Setup Details
Although most Web servers come with default settings for many
operational details, your Webmaster needs a good understanding
of what they mean, how they might be changed, and what effects
changes may have. For example, does your Web administration model
allow for user accounts on the system running your Web server?
If so, will you allow these users to create their own HTML documents
to be served or disable the default feature of the server software
that allows it? Further, if you allow users to create CGI scripts
in their home directory area, it's critical that your Webmaster
understand what the scripts do and educate users on the security
aspects of CGI. There are a number of other details of Web server
setup that need to be understood, most of which require a thorough
grounding in Windows NT system administration. These include
- Setting the server's TCP/IP port
number (usually 80 for Web servers).
- Configuring the login account under
which the server will run. (It isn't a good idea to run a Web
server under the system account and the administrator account
that are built into NT.)
- Maintaining and processing the server's
logfiles. If you don't routinely check the logfiles,
how will you ever know if there are security breaches or incorrect
hyperlinks in the HTML pages?
- Configuring and using Secure Sockets
Layer on the Web server and in the browsers.
- Understanding the MIME mechanism.
(See Chapter 12, "MIME and Helper
Applications.")
- Establishing virtual paths
on the Web server and configuring the default document to be served.
A related server question is: Do you want to permit "directory
browsing" when a URL with no explicit document is requested?
- Setting up document indexing
on the server. (See Chapter 21.)
- Understanding and using per-directory
access restrictions, including user passwords and groups and
TCP/IP network address restrictions to limit access to some or
all of your Web server's data.
- Understanding the security
and performance aspects of these and other choices and
how they interrelate.
You'll probably want to consult more detailed references on Web
server setup and administration. A good place to start is the
documentation that comes with the server software.
CGI Script Development
Creation of effective and safe CGI scripts (see Chapter 10,
"Intranet Security in Windows NT") requires not only
programming skills but also a fundamental understanding of NT
User Administration, the Web's Hypertext Transfer Protocol (HTTP),
and TCP/IP in general. Recall from Chapter 3,
"The Software Tools to Build a Web," that the CGI mechanism
works by taking the information entered in Web fill-in forms and
passing it as standard input to a back-end script
for processing. When finished, the back-end script returns the
results of its run as standard output, usually in the form
of HTML markup, which can be interpreted and displayed
by the user's Web browser software. I'll defer the comparison
of the CGI process with the ISAPI method until Chapter 19,
but suffice it to say, the two are similar.
Note |
CGI programs are also called CGI scripts or applications. The reason they are called scripts is that they can be written in Perl or the UNIX command shell, in which case they are interpreted rather than compiled, and the Web has a strong background in UNIX. When the C language or Visual Basic is used for CGI, the terms CGI program or CGI application are preferred to CGI script. Even simpler, some people just refer to all such things as CGIs.
|
Simple C GI scripts might use only a couple of pieces of information,
such as a simple text string for which to search and a list of
files in which to search for it. More complex ones, however, might
throw around a long list of input data, requiring elaborate variable
handling, use of data arrays, and use of underlying operating
system calls. Further, you'll want to validate data entered by
users before processing it. You'll probably not be able to manage
such complex scripts except in a full-feature programming language
like C or Perl. Experienced system administrators already have
a working knowledge of these languages, and this experience is
easily portable to CGI programming. Perl is widely used for CGI
scripting because of its power (including access to operating
system calls), portability, and relative ease of use.
Whether you use Perl, C, or some other programming language for
your CGI scripts, you need to be concerned about the security
aspects of the scripts. Although you're less likely to have efforts
to break the security of your Web server if your server is not
on the Internet, there are still good reasons to follow good security
practices. Programming languages like Perl and C include access
to underlying operating system resources, including the ability
to access, read, and manipulate memory and files. At the very
least, you need to make sure your scripts don't inadvertently
overwrite important files on your system or create memory buffer
overflows when users enter incorrect information in Web fill-in
forms. Curious, or in the extreme, malicious users might enter
harmful system commands in Web forms; your CGI scripts need to
validate the data that's entered to make sure nothing but appropriate
data gets executed on the server. Even simple typographical errors
are potential problems if data isn't validated. These security
considerations, of course, are even more important if your Web
server is accessible on the Internet.
If you are training to be a Webmaster and you want more information
about Perl or C, you might want to get David Till's book, Teach
Yourself Perl in 21 Days (ISBN 0-672-30586-0), also published
by Sams.net. Sams also has a wide range of reference books on
other programming languages such as Teach Yourself C Programming
in 21 Days, Premier Edition, by Peter Aitken and Brad Jones
(ISBN 0-672-30736-7).
By running your Intranet Web server on Windows NT, you'll find
several choices for your CGI scripting. In addition to Perl and
C, it's possible to use Visual Basic, particularly if your Web
server supports WinCGI. WinCGI was developed by Bob Denny to make
CGI scripting more accessible to the masses in the Web site server
from O'Reilly. As another alternative, Web Site Construction
Kit for Windows NT provides details about how you can take
advantage of VB and its ease of building a database interface
through ODBC (see Chapter 16 for more
information about ODBC databases), in cooperation with a standard
C program which performs the CGI tasks.
Java Programming Skills
Java applets are a little harder to identify because they have
characteristics in common with CGI scripts, HTML documents, and
Web browser helper applications. Like CGI scripts, applets are
computer programs that run on the user's computer, not on the
Web server. Like HTML documents, Java applets are first downloaded
from a Web server by clicking a hyperlink. The client machine
runs the applet and then discards it from memory when done. (It
stays on the local hard disk to avoid repetitive downloading in
case the same programs are needed again.) Helper applications,
on the other hand, are programs that already exist on the user's
computer and are run when data for the application is downloaded
from a Web server.
Java is a completely new programming language, something like
C++ in that it's object-oriented. As you might guess, it's hardware
and operating-system independent. Java applets run on any computer
system with a Java viewer or Java-compatible Web browser. Many
of the standard features of high-level programming languages have
purposely not been implemented in Java for both efficiency and
security reasons. For instance, Java can't access or manipulate
memory registers.
Security experts remain skeptical about the whole idea of running
unknown programs in a Web browser on a corporate LAN, or even
on a stand-alone PC. Remember, Java programs are automatically
downloaded from sources over which a system administrator has
no control. You are not being paranoid if you think this is more
than a little scary, assurances about Java's built-in security
features notwithstanding. Although Java applets are considered
immune from external virus infection, this issue should not be
taken for granted.
There is much new ground to be explored with Java for both possibilities
and risks. You'll likely need to learn Java programming if you
intend to use it on your Intranet, unless you know how to find
ready-made code that accomplishes the task you have in mind. Moreover,
you'll want to be intimately familiar with its possible security
implications for your customers. For SunSoft's view on Java, along
with extensive documentation, copies of the HotJava Web
browser, and demonstration Java applets, access the Java home
page (shown in Figure 4.1) at http://java.sun.com/. Also, Netscape
has Java demos at http://home.netscape.com/comprod/products/navigator/version2_0/java_applets/index.html.
Figure 4.1: The Sun Java Home Page is a virtual playground for Java lovers.
Web Server Security Skills
Even if your Intranet is completely isolated from the Internet,
and even if you trust all of your customers, it's still a good
idea to manage your Web server(s) with routine security. If you
do make your Web server(s) accessible on the Internet, doing so
becomes critical. Web server software like the IIS or Purveyor
packages have built-in security. To take full advantage of it
you need to understand the details of server security and the
NT User Manager for Domains.
As noted above, because CGI scripts run on your Web server, it's
critical you make sure there are no possibilities for them to
compromise the server's security through inappropriate data being
passed to them by malicious users. Just like you should inspect
any other software you may retrieve from the Internet or some
BBS before running it, make sure any CGI scripts you may download
are secure. You can only do this by inspecting and understanding
the scripts' code. In practice, this means you must understand
Perl because it is frequently the language of choice for CGI programming.
Your customers will likely demand to use fill-in forms on your
Intranet; some of them might even want to write their own CGI
scripts and/or obtain them from others. One of your security-related
decisions is that of restricting CGI scripts to your server's
protected filesystem or allowing users' CGI scripts to run out
of their own home directories. Choosing the latter means you need
to inspect the user scripts for security implications. This doesn't
mean you don't trust your customers who just want to get their
work done, which is the object, after all, of your Intranet. It
does mean you can't necessarily expect customers to be attuned
to the potential for intentional (or unintentional) misuse of
CGI scripts and their security aspects. You'll want to inspect
customer CGI scripts to make sure they're appropriately secure
and counsel users on them.
The security of your Web server is also impacted by the administrative
decisions you make with respect to managing your Web. Although
it's clear in the centralized model that only authorized people
can place Web documents and CGI scripts on your server, and you
can take the necessary practical and management steps to enforce
this policy, this is less clear in the other models.
Finally, your Web server is only as secure as the computer on
which it's running. All the security precautions in the world
are worth nothing if everyone in the office has the administrator
password to your server, or if you haven't closed well-known security
holes in the system. System and network security are meat and
potatoes to experienced NT System Administrators, and security
considerations alone present a strong argument for your Webmaster
to have an extensive background in system administration. These
considerations are especially important if your organization is
connected to the Internet. The overall security of your network
should be secured by a firewall system of some kind, and
you should carefully configure the access-control features of
your Web server(s) to limit access to authorized users.
By the way, the best NT System Administrators are often certified
through rigorous testing by Microsoft. Individuals who can pass
the test are given the badge of honor MCSE (Microsoft Certified
Systems Engineer). In addition to NT configuration, MCSEs are
usually skilled in at least one other technical product, such
as SQL Server.
Note |
As the word implies, a firewall system isolates your network from the Internet, limiting access between the two networks. Usually, firewalls are set up to permit certain Internet services, such as e-mail, to enter your network but block other services that might be insecure or subject to abuse. Firewalls can also be used to selectively permit access by users in an organization to outside Internet services, such as FTP or World Wide Web servers. For more information on Internet firewalls, see Internet Firewalls and Network Security, by Karanjit Siyan and Chris Hare (ISBN 1-56205-437-6), published by New Riders. Many commercial firewall vendors have Web pages, including Raptor Systems (http://www.raptor.com/), which has just ported its Eagle product line to Windows NT, Trusted Information Systems (http://www.tis.com/), with its Gauntlet product line, and others. For general firewall information, including access to the home pages of a long list of firewall and security vendors, see the Firewall Product Developers Consortium Web page, maintained by the National Computer Security Association, at http://www.ncsa.com/fwpdmem1.html. The NCSA (not to be confused with the National Center for Supercomputing Applications, makers of NCSA Mosaic and the NCSA httpd server) has a home page (see Figure 4.2) with useful security information at http://www.ncsa.com/.
|
Figure 4.2: The National Computer Security Association has a great deal of information about Internet security.
Here are a few more people skills you'll have to bring up with
your Intranet team. Leaving a PC Web server running unattended
in a non-secure area is an invitation to both the malicious and
the curious: You might as well forget any security on that server.
Viewer security is also a potential problem. Although you might
implement access control on your Web server (which will limit
user access to all or part of your Web server by specific TCP/IP
addresses or by password), remember that an unattended PC that
is already viewing protected documents is not secure. Let's say
you plan to restrict access to certain confidential personnel
information to management. You'll need to counsel management users
in these security issues. For example, leaving one's desk for
coffee while viewing confidential information without starting
up a screen lock or taking some other security measure defeats
all the Web server access controls.
General System Administration Skills
A final, catch-all set of Webmaster skills is the overall administration
of your Web server system. These skills range from everyday backups
of the system to performance tuning to disk-space and user account
management. Although routine in some respects, the performance
of these duties is a critical factor in the care and feeding of
your Intranet. Even if you have hardware and software maintenance/support
contracts with outside vendors, there's no substitute for the
experience and intuition of a System Administrator when problems
arise. Provided your System Administrator follows good backup
practices, for example, restoring lost or erroneously deleted
files can take just a few minutes. Webmasters and System Administrators
are also important in the training of your customers in the use
of your Web.
There are dozens of third-party training firms that run Microsoft
certified training programs and seminars, including intensive
system administration training at basic and advanced levels. A
beginner needs several weeks of these courses, particularly if
programming courses are required. Other alternatives include college
courses in programming. (C language is a frequent course offering,
even at community colleges.) You'll also find frequent one- and
two-day seminars on system administration subjects such as Perl.
The decisions you make on the management of your Intranet, theoretically
discussed in Chapter 2, come back into
play when you consider the skill sets your people need. (Of course,
this statement is easily stood on its head: The skills your people
have can help you choose the administrative model and might lead
you to reconsider earlier decisions.)
If you choose the decentralized model, you're deciding to leave
most, if not all, of the management and development of your Web
to its users, or at least to those interested enough to be setting
up individual Web servers for their own data. This model also
assumes the skills needed to do Web server setup, creation of
HTML files, and so forth, best reside at the user level. Similarly,
the need for training will be at the same level, with your customers
themselves deciding who needs what in the way of training.
In the centralized model these decisions are reversed, with the
delegation of responsibilities and the necessary skills focused
on your Webmaster(s). Here, you and your Webmaster(s) can determine
where training is required and, as noted previously, what training
you can provide to your customers, to develop and manage the training
process. In the more realistic mixed model, you delegate responsibilities
in a more flexible fashion, based on the needs of the components
of your organization.
It's also important for you to develop policies about customer
contributions to your Web. Besides regular customer feedback (see
the following), you should anticipate, if not solicit and welcome,
resources for your Intranet that are contributed by your customers.
Even if your Intranet follows the centralized model of administration,
it's important you recognize that customers often have the best
idea of what they want to see on it-especially if it's in their
area of expertise. Empowering customer input by providing a way
for them to contribute resources directly to your Intranet is
a fine way of developing both customers and your Intranet and
is sure to lead to further contributions.
We've already mentioned general System Administration training
opportunities. You'll also find a wide variety of Web-specific
training offerings from commercial vendors as well as short seminars
associated with major expositions and conferences. In fact, several
Web-specific conferences are already occurring on a regular basis;
you'll find advertisements for them in publications devoted to
Web subjects and networking. Here are a few:
Tip |
The first and foremost technical reference that every Windows NT System Administrator should have is the Windows NT Resource Kit published by Microsoft Press. The Resource Kit for NT 3.51 totaled five volumes. If you haven't already purchased the Resource Kit, be sure you wait until the Resource Kit for NT 4 comes out, because so much of the operating system has been enhanced.
|
You'll find courses in Web server administration, HTML markup,
CGI scripting, Perl, Java programming, VRML, network security,
and so on. In these publications, you'll also, find useful articles
on Web-related subjects, including technical features. Figure
4.3 shows the Web Developer magazine home page. If you want to
stay up on the hottest Web technology, it is a useful place to
drop by.
Figure 4.3: The Web Developer magazine home page includes current news about the Web.
If you have a competent Webmaster, there is no reason not to tap
her knowledge in running your own training courses on these same
subjects. She'll undoubtedly be answering questions from customers
on a regular basis, so you might as well formalize this relationship
with training courses. Of course, Webmasters cannot only train
the people who will use your Intranet, but other Webmasters as
well. Don't neglect the value of the wide variety of Web-related
books as training tools for users.
In Chapter 2, I recommended use of customer
focus groups to help define the purpose and content of
your Intranet. You should continue meeting with your focus groups
even after your Intranet is up and running; you might find even
more valuable feedback from your customers. Also expect customer
feedback outside your formal focus group arrangements.
They Inevitably Want More
Once your customers get the idea of using Web technology in their
everyday work, as opposed to recreational Web surfing,
they'll begin bombarding you with suggestions for changes and
requests for new information. Listen to these suggestions and
requests. As Chapter 2 suggested, your
customers know best the kinds of information they want to see
and how well your Web presents it. Employees often have useful
ideas on how to go about doing their jobs because they are the
people most intimately familiar with the jobs. Expect them to
have ideas for your Intranet as well for exactly the same reason.
If you've ever designed a database application, you know the iterative
design process. Even having gone through a formal process of soliciting
user input on your application before you ever started its design,
within minutes of the time you sit a user down in front of your
prototype, he's asking questions. For example:
- If I can do thus-and-so query, can't I
also do a that-and-so one?
- Wouldn't this data-entry screen be better
if this box's position and that box's were reversed?
- This is a great report, but can't you
fit it on one page? And while you're at it, how about showing
the quarterly figures, too?
In other words, real users using your application-whether it's
a corporate database or your Intranet- will quickly have ideas
on how it can be made better. Most of their ideas will be good
ones, too.
Get Them to Contribute
In your Intranet, customer ideas won't be limited to requests
for new information or changes in presentation. Users will quickly
recognize the collaborative aspects of Web technology.
Chapter 27, "Collaboration on Your
Intranet," discusses more about this aspect, but I should
touch on it here. Chapter 2, for instance,
suggested the idea of engineers and scientists sharing engineering
drawings, application datafiles, and/or technical reports with
colleagues by placing them on your Web. As a Web designer, you
can't possibly identify this sort of specific information, but
your engineer and scientist customers surely can and will.
Regardless of the administrative model you've selected for your
Web, it's important you make it easy for customers to contribute
resources for it. This is where the decentralized and mixed models
shine: Customers using your Web can create and make their
own resources available on your Web for sharing with other
customers.
Simple HTML markup is easily within the grasp of just about anyone
who uses a computer, as are most of the legacy data conversion
tools described in Chapter 3. Point-and-click
setup of a Windows Web server makes it possible for almost anyone
to set up a bare-bones Web server on his desktop to share these
specific resources. Just as anyone can thumb tack a notice on
a cork bulletin board in the office, on your Intranet he can tack
up CAD drawings of circuit boards, building blueprints, or directions
to the office holiday party. You might also want to set up a free-for-all,
fill-in form on your Web that allows customers to add links to
their resources.
Customer contributions might turn out to be the most important
aspect of your Intranet. To this end, make sure your customer
training and Web-related communications emphasizes the value and
continuing need for their input. It's vitally important that you
create a welcoming, inclusive atmosphere. Your Intranet is, after
all, for your customers. Involving them in the Intranet design
process and then keeping them involved by welcoming their contributions,
ensures its value, to them and to your organization. Losing this
customer focus, on the other hand, will lead to your Intranet
becoming stale and unused; if customers find no value, they'll
go elsewhere.
This chapter has focused on the people skills you'll need in setting
up, running, and using your Intranet. You've learned about
- The skills required for the setup and
administration of your Intranet server(s).
- How your people skills interrelate with
administrative and substantive responsibilities in your Intranet.
- Training, for both you and your customers.
- Getting and responding to customer feedback.
Chapter 5 furthers the discussion of Intranet
fundamentals by diving into HTML. You will find that HTML is really
pretty easy to learn, and you will see that these skills are essential
to understanding the Web.

Contact
reference@developer.com with questions or comments.
Copyright 1998
EarthWeb Inc., All rights reserved.
PLEASE READ THE ACCEPTABLE USAGE STATEMENT.
Copyright 1998 Macmillan Computer Publishing. All rights reserved.